Applicant 
Appl. No. 
Examiner 
Docket No, 



Scott Montgomery 

09/990,341 

Edward R. Cosimano 

703602.2 



Amendments to the Specification 



Please replace the paragraphs [0089], [0101], [0157], [0158], [0159], [0160], [0165], 
[0173], [0179], [0180], [0184], and [0189] with the following amended paragraphs. Although 
the original patent application was filed without paragraph numbers, the published application 
included paragraph numbers. These paragraph numbers are identical to corresponding U.S. 
Publication No. 2003/0101 148 Al, published May 29, 2003. 

[0089] Turning now to FIGS. 4-7 and 33, the structural details of the postage system 300 
will now be described. With specific reference to FIG. 4, each end user computer 308 contains 
conventional computer hardware, including a user interface 402 with a keyboard 403, printer 
404, display 405, and optional scale 406 for weighing mail pieces, data processing circuitry 408 
(such as, e.g., a Central Processor Unit (CPU)) for executing programs, a communications 
interface 410 (such as, e.g., a modem, LAN connection, or Internet connection) for handling 
communications with the centralized postage-issuing computer system 305/306/307 over the 
communications link 314 or for handling communications with the master tracking computer 
system 310 over the communications link 322, and local memory 411. The user interface 402 is 
configured to allow the end user to request unique tracking H) f s and self- validating unique 
postage indicia and to enter postage information associated with the unique tracking ID and 
postage indicium requests, as well as to print the unique tracking ID's and self-validating unique 
postage indicia on mail pieces. The local memory 411, which will typically include both random 
access memory and non- volatile disk storage, stores a set of mail handling procedures that are 
embodied in various software modules 412, and an end user database 415 that contains 
information needed by mail handling modules 412, including local account balance information, 
transaction records representing all recent postage purchase transaction by the end user computer 
308, and session encryption keys. Although the local memory 41 1 is depicted in FIG. 4 as a 
single memory device, it should be understood that it can be implemented in a multitude of 
memory devices as well. 

[0101] Referring specifically to FIG. 5, the centralized postage-issuing computer system 
306 differs from the centralized postage-issuing computer system 305 in that it provides means 
through which the master tracking computer system 310 issue tracking ID f s to the end user 
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computers 308. To the extent that the components of centralized postage-issuing computer 
systems 305 and 306 are similar, identical reference numbers have been used. In addition to the 
components contained in the centralized postage-issuing computer system 305, the centralized 
postage-issuing computer system 306 comprises postage dispensing modules 426, which 
additionally include a tracking ID request module 438 and a communications module 434. The 
tracking ID request module 438 is configured for generating and transmitting requests for unique 
tracking ID f s to the master tracking computer system 310 in response to receiving requests for 
unique tracking ID's from the end user computers 308. These requests take the form of query 
streams and contain the same information as in the tracking ED requests generated by the 
tracking ID request module 414 in each of the end user computers 308. The communications 
module 434 is configured for handling communications with the end user computers 308 over 
the communications links 314 (such as, e.g., receiving tracking ID requests and postage indicium 
requests and transmitting tracking ID's and unique postage indicia). The communications module 
434 is further configured for handling communications with the master tracking computer system 
310 over the communications link 316 (such as, e.g., transmitting tracking ED requests and 
receiving tracking ID's). 

[0157] At steps 1012 and 1014, the postage validation computer system 362 receives the 
self- validating postage indicium from the centralized postage-issuing computer system 356 and 
displays its contents to the postal verifier. In particular, the communications interface 882 then, 
under control of the communications module 892, receives the self- validating postage indicium 
from the centralized postage-issuing computer system 356 over the communications link 368 
(step 1012), and the postage scanning station 884 displays its contents to the postal verifier (step 
1012). At step 1014, the verifier then manually compares the contents of the self-validating 
postage indicium to the human-readable information (e.g., mailing date, postage amount, origin 
of mail piece, and destination of mail piece) on the mail piece. If the contents of the self- 
validating postage indicium do not match the human-readable information, this is an indication 
of likely fraudulent use of a postage indicium and is treated as such. 

[0158] At steps 1016-1018, the postal verifier validates the postage indicium itself by 
operating the postage indicia validation module 894. In particular, the public key association 
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submodule 896 obtains from the set of public keys 897 the public key corresponding to the 
Certificate Serial Number (item #3 in Table 2) within the postage indicium (step 1016). The 
digital signature verification submodule 898 then verifies the digital signature of the postage 
indicium to determine if they are consistent (step 1018). If the verification process returns a 
Boolean true, this indicates that the postage indicium was in fact generated by a secure central 
computer 356 for a mail piece of the same approximate weight, origin and destination as the mail 
piece being processed. If copy fraud is to be detected, a copy fraud detection process using 
unique identifiers or similar to the process disclosed with respect to FIG. 14 can be utilized. 

[0159] After the postage has been validated or rejected, the database management module 
893 stores the postage information, along with the results of the validation process (step 1020). If 
valid, the mail piece is then submitted for normal delivery processing (step 1022). 

[0160] It should be noted that rather than have the postal verifier validate the postage 
indicium, the centralized postage-issuing computer system 356 itself can validate the postage 
indicium. In this case, the postage indicia validation module 894 will be located in the 
centralized postage-issuing computer system 356. Thus, after the centralized postage-issuing 
computer system 356 retrieves the self-validating postage indicium corresponding to the 
indexing identifier at step 1008, it will validate the postage indicium itself using a corresponding 
public key. If it is valid, the centralized postage-issuing computer system 356 will transmit a 
Boolean true, along with the already validated postage indicium, to the postage validation 
computer system 362, which will then perform postage validation steps 1014, 1016, 1018, and 
1020. If it is invalid, the centralized postage-issuing computer system 356 will transmit a 
Boolean false to the postage validation computer system 362, which will then store the results of 
the validation process as being invalid at step 1020. 

[0165] Referring to FIG. 37, and with general reference to FIGS, 34-36, the procedures 
for verifying the sender of a mail piece will now be described. It is assumed that the tracking ID 
(as the indexing identifier) and sender identification information, along with the postage 
information, has already been recorded in the centralized postage-issuing computer system 356, 
and specifically the postage database 830, when the tracking number and postage was issued to 
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the end user (presumably, the sender of the mail piece). At steps 1400-1404, the mail recipient 
computer 378 generates and transmits a request for sender identification information to the 
centralized postage-issuing computer system 356 by entering the tracking ID printed on the 
received mail piece into the user interface 1302, which displays a window similar to the one 
illustrated in FIG. 34. The sender identification request module 1314 then generates a sender 
identification request with the associated tracking ID (step 1402). The communications interface 
1310 then, under control of the communications module 1318, transmits the sender identification 
request over the communications link 384 (step 1404). 

[0173] It should be noted that the date of this query is Aug. 23, 2001, and the postage 
transactions in question were completed three days earlier. The USPS delivery status for the first 
package presents the phrase "Your item was accepted at 10 pm on August 21 in Palo Alto, Calif. 
94301. This phrase is misleading in that it infers that the USPS actually took possession of this 
package. In reality, it only indicates the date/time in which the tracking information was posted 
to the master tracking computer system. When this message persists for days or weeks, one must 
conclude that the tracking ID was indeed issued, but the package never entered the postal system. 
As another example, an audit inquiry can reveal all postage transaction information in a specific 
user account. 

[0179] Specifically, the postage dispensing/refund eligibility modules 1 126 include a 
communications module 1 134, database management module 1 136, tracking ID request module 
1 138, postage indicium request validation module 1 140, postage indicium generation module 
1 142, delivery status request module 1 143, filtering module 1 145, refund inquiry module 1 147, 
and refund display module 1 149. The delivery status request module 1 143 is configured for 
generating a request for the delivery status for each tracking ID stored in the postage database 
1 130. The filtering module 1 145 is configured for variously generating refund information by 
filtering and formatting the postage transaction information retrieved from the postage database 
1 130, as will be described in further detail below. In addition to being configured for providing 
the communications previously described with respect to the communications module 434, the 
communications module 1 134 is configured for transmitting delivery status requests to, and 
receiving confirmatory delivery status information from, the master tracking computer system 
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390 over the communications link 396. 

[0180] The database management module 1 136 is configured for storing and retrieving 
pertinent information in and from the customer database 1 128, postage database 1 130, and 
finance database 1 132. This function includes storing and retrieving a tracking ID and an 
associated delivery status, and updating that associated delivery status with confirmatory 
delivery status information received from the master tracking computer system 390. As will be 
described in further detail, the confirmatory delivery status information indicates whether a mail 
piece carrying a tracking ID has, in fact, been delivered. The refund inquiry module 1 147 is 
configured for generating an inquiry for postage refund information. In the illustrated 
embodiment, the inquiry contains a user account ID and password and the refund inquiry, which 
as previously discussed, can include various types. The refund display module 1 149 is 
configured for displaying on the display 1 127 the postage refund information filtered by the 
filtering module 1145. 

[0184] The tracking information maintenance modules 1 170 include a communications 
module 1 174, tracking ID allocation module 1 176, database management module 1 178, and 
refunded postage polling module 1 180. In addition to being configured for providing the 
communications previously described with respect to the communications module 474, the 
communications module 1 174 receives delivery status requests from, and transmits confirmatory 
delivery status information to, each centralized postage-issuing computer system 386 over the 
communications links 396. The confirmatory delivery status information is obtained from 
tracking stations (not shown), which scan tracked mail pieces when they are delivered. The 
tracking ED allocation module 1 176 is configured for performing the same functions as the 
tracking ED allocation module 476 previously described in the master tracking computer system 
310. The database management module 1 178 is configured for storing and retrieving assigned 
tracking ED ! s and associated postage information (including delivery status) to and from the 
tracking information database 1 172. The database management module 1 178 is further 
configured for updating the tracking information database 1 172 with refund information. That is, 
if a specific postage transaction has been refunded, the database management module 1 178 will 
associate a refund indicator with the postage information relating to the specific postage 
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transaction. The refunded postage polling module 1 180 periodically polls the tracking 
information database 1 172 to determine if a mail piece associated with any refunded postage 
transaction has been delivered. 

[0189] Referring to specifically FIG. 32, and with general reference to FIG. 29, the 
procedures for issuing a refund will now be described. At step 1230, the account administrator 
operates the user interface 1 123 of the centralized postage-issuing computer system 386 to make 
a refund inquiry. The type of refund inquiry can be, e.g., any of the three refund inquiries 
described above (refund eligible inquiry, audit review, or refund pattern audit), but for purposes 
of the following explanation the refund eligible inquiry will be described. At step 1232, the 
database management module 1 136 retrieves for a specific user account the postage transaction 
information from the postage database 1 130. At step 1234, the filtering module 1 145 selects the 
postage transaction information representing duplicative postage transaction. In particular, it 
selects the postage transactions that carry tracking ID's that have never been refunded in the past, 
that are issued for the specific user account, and that have identical key postage transaction 
items, i.e., postage transaction date, destination zip code, service class, and postage amount. At 
step 1236, the filtering module 1 145 then determines if any of the selected postage transactions 
have been previously refunded. If so, it is determined that a refund for that postage transaction is 
forthcoming. In this case, the database management module 1 136, at step 1238, credits the user ! s 
account for the misprint in the finance database 1 132. At step 1240, the database management 
module 1 136 then date/time stamps the misprint postage transaction in the postage database 
1 130. In this manner, the filtering module 1 145 will filter out this refunded postage transaction in 
the future, so that it is not refunded multiple times. At step 1242, the account administrator issues 
a refund request to the postage refund center 392 of the postal authority (e.g., USPS). 
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